home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1377.txt < prev    next >
Text File  |  1994-08-01  |  22KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            D. Katz
  8. Request for Comments: 1377                                         cisco
  9.                                                            November 1992
  10.  
  11.  
  12.           The PPP OSI Network Layer Control Protocol (OSINLCP)
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  25.    encapsulating Network Layer protocol information over point-to-point
  26.    links.  PPP also defines an extensible Link Control Protocol, and
  27.    proposes a family of Network Control Protocols (NCPs) for
  28.    establishing and configuring different network-layer protocols.
  29.  
  30.    This document defines the NCP for establishing and configuring OSI
  31.    Network Layer Protocols.
  32.  
  33.    This memo is the product of the Point-to-Point Protocol Working Group
  34.    of the Internet Engineering Task Force (IETF).  Comments on this memo
  35.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  36.  
  37. Table of Contents
  38.  
  39.    1.     Introduction ..........................................    2
  40.    1.1    OSI Network Layer Protocols over PPP ..................    2
  41.    2.     A PPP Network Control Protocol (NCP) for OSI ..........    5
  42.    2.1    Sending OSI NPDUs .....................................    6
  43.    2.2    NPDU Alignment ........................................    6
  44.    2.3    Network Layer Addressing Information ..................    6
  45.    3.     OSINLCP Configuration Options .........................    7
  46.    3.1    Align-NPDU ............................................    7
  47.    REFERENCES ...................................................    9
  48.    ACKNOWLEDGEMENTS .............................................    9
  49.    SECURITY CONSIDERATIONS ......................................   10
  50.    CHAIR'S ADDRESS ..............................................   10
  51.    AUTHOR'S ADDRESS .............................................   10
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Katz                                                            [Page 1]
  59.  
  60. RFC 1377                      PPP OSINLCP                  November 1992
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65.    PPP has three main components:
  66.  
  67.       1. A method for encapsulating datagrams over serial links.
  68.  
  69.       2. A Link Control Protocol (LCP) for establishing, configuring,
  70.          and testing the data-link connection.
  71.  
  72.       3. A family of Network Control Protocols (NCPs) for establishing
  73.          and configuring different network-layer protocols.
  74.  
  75.    In order to establish communications over a point-to-point link, each
  76.    end of the PPP link must first send LCP packets to configure and test
  77.    the data link.  After the link has been established and optional
  78.    facilities have been negotiated as needed by the LCP, PPP must send
  79.    NCP packets to choose and configure one or more network-layer
  80.    protocols.  Once each of the chosen network-layer protocols has been
  81.    configured, datagrams from each network-layer protocol can be sent
  82.    over the link.
  83.  
  84.    The link will remain configured for communications until explicit LCP
  85.    or NCP packets close the link down, or until some external event
  86.    occurs (an inactivity timer expires or network administrator
  87.    intervention).
  88.  
  89. 1.1.  OSI Network Layer Protocols over PPP
  90.  
  91.    A number of protocols have been defined for the Network Layer of OSI,
  92.    including the Connectionless Network Layer Protocol (CLNP, ISO 8473)
  93.    [3], the End System to Intermediate System routing protocol (ES-IS,
  94.    ISO 9542) [4], the Intermediate System to Intermediate System routing
  95.    protocol (IS-IS, ISO 10589) [5], and the Inter-Domain Routeing
  96.    Protocol (IDRP, CD 10747) [6].  Generally, these protocols were
  97.    designed to run over non-reliable data link protocols such as PPP.
  98.  
  99.    Network Layer Protocol Identifier (NLPID)
  100.  
  101.       OSI Network Layer protocols can be discriminated according to the
  102.       first octet in each Network Protocol Data Unit (NPDU, that is,
  103.       packet), known as the Network Layer Protocol Identifier (NLPID),
  104.       which is defined in ISO/TR 9577 [7].  This allows the various
  105.       protocols to be run over a common data link without any
  106.       discriminator below the network layer.
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Katz                                                            [Page 2]
  115.  
  116. RFC 1377                      PPP OSINLCP                  November 1992
  117.  
  118.  
  119.    Inactive Network Layer Protocol
  120.  
  121.       ISO/TR 9577 reserves a NLPID value of zero to represent the
  122.       "Inactive Network Layer Protocol", as defined in ISO 8473.  The
  123.       inactive network layer protocol MUST NOT be used over PPP.  This
  124.       assures that whichever OSI network layer protocol is used will
  125.       have a non-zero NLPID value.
  126.  
  127.    Connection-Oriented Network Protocol
  128.  
  129.       The OSI Connection-Oriented Network Protocol (ISO 8208) [8],
  130.       effectively the Packet Layer of CCITT X.25, is intended to be run
  131.       over a reliable data link, such as IEEE 802.2 type II or LAPB.
  132.       Therefore, the unreliable data link service provided by PPP is not
  133.       appropriate for use with ISO 8208.
  134.  
  135.    ConnectionLess Network Protocol (CLNP)
  136.  
  137.       The ConnectionLess Network Protocol offers a simple non-reliable
  138.       datagram service very similar to IP, and is designed to run over a
  139.       non-reliable data link service, such as provided by PPP.
  140.  
  141.    End-System to Intermediate-System Protocol (ES-IS)
  142.  
  143.       ES Hellos and IS Hellos are retransmitted on a periodic timer-
  144.       driven basis (based on expiration of the "Configuration Timer").
  145.       The resulting ES and IS configuration information is invalidated
  146.       on a timer driven basis, based on expiration of the "Holding
  147.       Timer" for each piece of information.  The value of a Holding
  148.       Timer is set by the source of the information, and transmitted in
  149.       the Holding Time field of the appropriate ES-IS packet.  ISO 9542
  150.       recommends that the holding time field is set to approximately
  151.       twice the Configuration Timer parameter, such that even if every
  152.       other Hello packet is lost the configuration information will be
  153.       retained (implying that the Holding Timer is actually set to
  154.       slightly more than twice the Configuration Timer).
  155.  
  156.       Generally, the recommendation in ISO 9542 is sufficient for PPP
  157.       links.  For very unreliable links, it may be necessary to set the
  158.       Holding Timer to be slightly more than three times the
  159.       Configuration Timer to ensure that loss of configuration
  160.       information is an unusual event.
  161.  
  162.       Redirect information is not transmitted on point-to-point links,
  163.       but may be transmitted on general topology subnetworks, which in
  164.       turn may make use of PPP.  Redirect information is sent on a
  165.       event-driven basis (based on a CLNP packet being forwarded by a
  166.       router out the incoming interface), but redirect information is
  167.  
  168.  
  169.  
  170. Katz                                                            [Page 3]
  171.  
  172. RFC 1377                      PPP OSINLCP                  November 1992
  173.  
  174.  
  175.       invalidated on a timer-driven basis.  Loss of a single redirect
  176.       may result in a subsequent data packet being sent to the same
  177.       incorrect router, which will re-issue the redirect.  This operates
  178.       in the same manner as ICMP redirects for IP packets, and does not
  179.       pose any problem for operation over PPP links.
  180.  
  181.    Intermediate-System to Intermediate-System Protocol (IS-IS)
  182.  
  183.       IS-IS allows for broadcast links (typically LANs), point-to-point
  184.       links (such as PPP), and general topology links (such as X.25
  185.       networks) which are modelled as a collection of point-to-point
  186.       links.
  187.  
  188.       There are four types of IS-IS packets: IS-IS Hello Packets, Link
  189.       State Packets (LSPs), Complete Sequence Number Packets (CSNPs),
  190.       and Partial Sequence Number Packets (PSNPs).
  191.  
  192.       IS-IS Hello messages are transmitted periodically on point-to-
  193.       point links (based on expiration of the "ISISHello" timer).
  194.       Routers expect to receive IS-IS Hello packets periodically.
  195.       Specifically, the IS-IS Hello packet specifies a "Holding Time".
  196.       If no subsequent IS-IS Hello is received over the corresponding
  197.       link for the specified time period, then the neighboring router is
  198.       assumed to have been disconnected or to be down.  It is highly
  199.       undesireable for links to "flap" up and down unnecessarily, which
  200.       implies that the holding time needs to be large enough that a link
  201.       is very unlikely to be declared down due to a failure to receive
  202.       an IS-IS Hello.  This implies that running IS-IS over unreliable
  203.       data links requires the Holding time to be greater than "k" times
  204.       the ISISHello timer, where k is chosen such that the loss of k
  205.       consecutive IS-IS Hello's is rare.  If the quality of the link is
  206.       poor, then the Holding Time will need to be increased or the
  207.       "ISISHello" time decreased.
  208.  
  209.       LSPs are acknowledged by the IS-IS protocol (via use of partial
  210.       sequence number packets).  A lost LSP will be recovered from with
  211.       no problem provided that PPP links are treated the same way as
  212.       other point-to-point links.  On those rare occasions where a
  213.       partial sequence number packet is lost, this might result in the
  214.       retransmission of a link state packet over a single link, but will
  215.       not impact the correct operation of the routing algorithm.
  216.  
  217.       CSNPs are sent upon link startup on a point-to-point link.  This
  218.       does not need to be changed for PPP.  If a CSNP fragment is lost
  219.       upon startup it is merely loss of an optimization -- LSPs that did
  220.       not need to be transmitted over the link will be transmitted.  If
  221.       a periodic CSNP fragment is lost it merely means that detection of
  222.       low probability database corruption will take longer.
  223.  
  224.  
  225.  
  226. Katz                                                            [Page 4]
  227.  
  228. RFC 1377                      PPP OSINLCP                  November 1992
  229.  
  230.  
  231.       PSNPs function as ACKs.  Loss of a PSNP may result in an
  232.       unnecessary retransmission of an LSP, but does not prevent correct
  233.       operation of the routing protocol.
  234.  
  235.    Inter-Domain Routeing Protocol (IDRP)
  236.  
  237.       IDRP expects to run over datagram links, but requires reliable
  238.       exchange of IDRP information.  For this reason, IDRP contains
  239.       built-in reliability mechanisms which ensure that packets will be
  240.       received correctly.
  241.  
  242. 2.  A PPP Network Control Protocol (NCP) for OSI
  243.  
  244.    The OSI Network Layer Control Protocol (OSINLCP) is responsible for
  245.    configuring, enabling, and disabling the OSI protocol modules on both
  246.    ends of the point-to-point link.  OSINLCP uses the same packet
  247.    exchange machanism as the Link Control Protocol (LCP).  OSINLCP
  248.    packets may not be exchanged until PPP has reached the Network-Layer
  249.    Protocol phase.  OSINLCP packets received before this phase is
  250.    reached should be silently discarded.
  251.  
  252.    The OSI Network Layer Control Protocol is exactly the same as the
  253.    Link Control Protocol [1] with the following exceptions:
  254.  
  255.    Frame Modifications
  256.  
  257.       The packet may utilize any modifications to the basic frame format
  258.       which have been negotiated during the Link Establishment phase.
  259.  
  260.    Data Link Layer Protocol Field
  261.  
  262.       Exactly one OSINLCP packet is encapsulated in the Information
  263.       field of a PPP Data Link Layer frame where the Protocol field
  264.       indicates type hex 8023 (OSI Network Layer Control Protocol).
  265.  
  266.    Code field
  267.  
  268.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  269.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  270.       and Code-Reject) are used.  Other Codes should be treated as
  271.       unrecognized and should result in Code-Rejects.
  272.  
  273.    Timeouts
  274.  
  275.       OSINLCP packets may not be exchanged until PPP has reached the
  276.       Network-Layer Protocol phase.  An implementation should be
  277.       prepared to wait for Authentication and Link Quality Determination
  278.       to finish before timing out waiting for a Configure-Ack or other
  279.  
  280.  
  281.  
  282. Katz                                                            [Page 5]
  283.  
  284. RFC 1377                      PPP OSINLCP                  November 1992
  285.  
  286.  
  287.       response.  It is suggested that an implementation give up only
  288.       after user intervention or a configurable amount of time.
  289.  
  290.    Configuration Option Types
  291.  
  292.       OSINLCP has one Configuration Option, which is defined below.
  293.  
  294. 2.1.  Sending OSI NPDUs
  295.  
  296.    Before any Network Protocol Data Units (NPDUs) may be communicated,
  297.    PPP must reach the Network-Layer Protocol phase, and the OSI Network
  298.    Layer Control Protocol must reach the Opened state.
  299.  
  300.    Exactly one OSI NPDU is encapsulated in the Information field of a
  301.    PPP Data Link Layer frame where the Protocol field indicates type hex
  302.    0023 (OSI Network Layer).
  303.  
  304.    The maximum length of an OSI NPDU transmitted over a PPP link is the
  305.    same as the maximum length of the Information field of a PPP data
  306.    link layer frame.  Larger NPDUs must be segmented as necessary.  If a
  307.    system wishes to avoid segmentation and reassembly, it should use
  308.    transport layer mechanisms to discourage others from sending large
  309.    PDUs.
  310.  
  311. 2.2.  NPDU Alignment
  312.  
  313.    OSI protocols have peculiar alignment problems due to the fact that
  314.    they are often encapsulated in data link protocols with odd-length
  315.    headers, while PPP defaults to even-length headers.  A router
  316.    switching an OSI packet may find that the beginning of the packet
  317.    falls on an inconvenient memory boundary when the hardware used to
  318.    transmit the packet to its next hop requires a particular alignment.
  319.    This situation can be addressed by the use of leading zero padding.
  320.  
  321.    When sending, an implementation MAY insert one to three octets of
  322.    zero between the PPP header and the OSI NPDU.  These zero octets
  323.    correspondingly reduce the maximum length of the NPDU that may be
  324.    transmitted.
  325.  
  326.    On reception, any such leading zero octets (if present) MUST be
  327.    removed.  Regardless of whether leading zero padding is used, an
  328.    implementation MUST also be able to receive a PPP packet with any
  329.    arbitrary alignment of the NPDU.
  330.  
  331. 2.3.  Network Layer Addressing Information
  332.  
  333.    OSINLCP does not define a separate configuration option for the
  334.    exchange of OSI Network Layer address information.  Instead, the ES-
  335.  
  336.  
  337.  
  338. Katz                                                            [Page 6]
  339.  
  340. RFC 1377                      PPP OSINLCP                  November 1992
  341.  
  342.  
  343.    IS protocol, ISO 9542, should be used.  This protocol provides a
  344.    mechanism for determining the Network Layer address(es) of the
  345.    neighbor on the link, as well as determining if the neighbor is an
  346.    End System or an Intermediate System.
  347.  
  348.    A draft addendum to ES-IS [9] is being defined in ISO to add support
  349.    for dynamic address assignment.  This addendum has currently passed
  350.    the formal "Committee Draft" (CD) letter ballot.
  351.  
  352. 3.  OSINLCP Configuration Options
  353.  
  354.    OSINLCP Configuration Options allow negotiatiation of desirable
  355.    Internet Protocol parameters.  OSINLCP uses the same Configuration
  356.    Option format defined for LCP [1], with a separate set of Options.
  357.  
  358.    The most up-to-date values of the OSINLCP Option Type field are
  359.    specified in the most recent "Assigned Numbers" RFC [2].  Current
  360.    values are assigned as follows:
  361.  
  362.       1       Align-NPDU
  363.  
  364. 3.1.  Align-NPDU
  365.  
  366.    Description
  367.  
  368.       This Configuration Option provides a way for the receiver to
  369.       negotiate a particular alignment of the OSI NPDU.  Empirical
  370.       evidence suggests that the greatest time deficit for re-alignment
  371.       exists at the receiver.
  372.  
  373.       The alignment is accomplished through combination of PPP header
  374.       compression with leading zero padding (see above).  It is
  375.       recommended that alignment be entirely through header compression
  376.       combinations whenever possible.  For example, an alignment of 3
  377.       could be achieved by combining uncompressed PPP Address and
  378.       Control fields (2 octets) with a compressed PPP Protocol field (1
  379.       octet).
  380.  
  381.       This option is negotiated separately in each direction.  A
  382.       receiver which does not need alignment MUST NOT request the
  383.       option.  A sender which desires alignment prior to sending SHOULD
  384.       Configure-Nak with an appropriate value.
  385.  
  386.          Implementation Note: In a complex environment, there might be
  387.          several conflicting needs for alignment.  It is recommended
  388.          that the receiver request alignment based on the needs of the
  389.          highest speed next hop link.  Also, greater efficiency might be
  390.          obtained by negotiating upstream the values requested by
  391.  
  392.  
  393.  
  394. Katz                                                            [Page 7]
  395.  
  396. RFC 1377                      PPP OSINLCP                  November 1992
  397.  
  398.  
  399.          downstream PPP links, since those packets will not need a
  400.          change in alignment on transit.
  401.  
  402.       The alignment request is advisory, and failure to agree on an
  403.       alignment MUST NOT prevent the OSINLCP from reaching the Opened
  404.       state.  By default, the alignment is done according to the needs
  405.       of the sender, and all receivers MUST be capable of accepting
  406.       packets with any alignment.
  407.  
  408.          Vernacular: If you don't like this option, you can refuse to
  409.          negotiate it, and you can send whatever alignment you want.
  410.          However, if you accept the peer's alignment option, then you
  411.          MUST transmit packets with the agreed alignment.
  412.  
  413.    A summary of the Align-NPDU Configuration Option format is shown
  414.    below.  The fields are transmitted from left to right.
  415.  
  416.     0                   1                   2
  417.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  418.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.    |     Type      |    Length     |   Alignment   |
  420.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.  
  422.    Type
  423.  
  424.       1
  425.  
  426.    Length
  427.  
  428.       3
  429.  
  430.    Alignment
  431.  
  432.       This field specifies the offset of the beginning of the OSI NPDU
  433.       relative to the beginning of the PPP packet header (not including
  434.       any leading Flag Sequences).
  435.  
  436.       A value of 1 through 4 requires an offset of that specific length,
  437.       modulo 4.  For example, a value of 1 would require no padding when
  438.       the PPP Address, Control, and Protocol fields are compressed.  One
  439.       octet of leading zero padding would be necessary when the PPP
  440.       header is full sized.
  441.  
  442.       A value of 255 requests an offset of an odd length (1 or 3).  A
  443.       value of 254 requests an offset of an even length (2 or 4).  If
  444.       the sender is not capable of dynamically varying the amount of
  445.       padding, it MUST NAK with one of the two specific values.
  446.  
  447.  
  448.  
  449.  
  450. Katz                                                            [Page 8]
  451.  
  452. RFC 1377                      PPP OSINLCP                  November 1992
  453.  
  454.  
  455. References
  456.  
  457.    [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
  458.        Daydreamer, May 1992.
  459.  
  460.    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  461.        USC/Information Sciences Institute, July 1992.
  462.  
  463.    [3] ISO, "Information processing systems -- Data communications --
  464.        Protocol for providing the connectionless-mode network
  465.        service", ISO 8473, 1988.
  466.  
  467.    [4] ISO, "Information processing systems -- Telecommunications and
  468.        information exchange between systems -- End system to
  469.        Intermediate system Routeing exchange protocol for use in
  470.        conjunction with the protocol for providing the connectionless-
  471.        mode network service (ISO 8473)", ISO 9542, 1988.
  472.  
  473.    [5] ISO, "Information processing systems -- Telecommunications and
  474.        information exchange between systems -- Intermediate system to
  475.        Intermediate system Intra-Domain routeing exchange protocol for
  476.        use in conjunction with the protocol for providing the
  477.        connectionless-mode network service (ISO 8473)", ISO 10589,
  478.        1990.
  479.  
  480.    [6] ISO, "Protocol for Exchange of Inter-domain Routeing
  481.        Information among Intermediate Systems to Support Forwarding of
  482.        ISO 8473 PDUs", ISO CD 10747, 1991.
  483.  
  484.    [7] ISO, "Information technology -- Telecommunications and
  485.        information exchange between systems -- Protocol identification
  486.        in the network layer", ISO/IEC TR9577:1990.
  487.  
  488.    [8] ISO, "Information processing systems -- Data communications --
  489.        X.25 packet level protocol for Data terminal equipment", ISO
  490.        8208, 1984.
  491.  
  492.    [9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery
  493.        of OSI NSAP Addresses by End Systems)", SC6/N7248.
  494.  
  495. Acknowledgments
  496.  
  497.    Some of the text in this document is taken from previous documents
  498.    produced by the Point-to-Point Protocol Working Group of the Internet
  499.    Engineering Task Force (IETF).
  500.  
  501.    Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com), for
  502.    contributions of text and design suggestions based on implementation
  503.  
  504.  
  505.  
  506. Katz                                                            [Page 9]
  507.  
  508. RFC 1377                      PPP OSINLCP                  November 1992
  509.  
  510.  
  511.    experience.
  512.  
  513.    Thanks also to Bill Simpson for his editing and formatting efforts,
  514.    both for this document and for PPP in general.
  515.  
  516. Security Considerations
  517.  
  518.    Security issues are not discussed in this memo.
  519.  
  520. Chair's Address
  521.  
  522.    The working group can be contacted via the current chair:
  523.  
  524.    Brian Lloyd
  525.    Lloyd & Associates
  526.    3420 Sudbury Road
  527.    Cameron Park, California 95682
  528.  
  529.    Phone: (916) 676-1147
  530.    EMail: brian@lloyd.com
  531.  
  532. Author's Address
  533.  
  534.    Questions about this memo can also be directed to:
  535.  
  536.    Dave Katz
  537.    cisco Systems, Inc.
  538.    1525 O'Brien Dr.
  539.    Menlo Park, CA  94025
  540.  
  541.    Phone: (415) 688-8284
  542.    EMail: dkatz@cisco.com
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Katz                                                           [Page 10]
  563.  
  564.